home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1543.txt < prev    next >
Text File  |  1994-08-01  |  31KB  |  900 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Postel
  8. Request for Comments: 1543                                           ISI
  9. Obsoletes: RFCs 1111, 825                                   October 1993
  10. Category: Informational
  11.  
  12.  
  13.                       Instructions to RFC Authors
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Table of Contents
  22.  
  23.    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
  24.    2.   Editorial Policy . . . . . . . . . . . . . . . . . . . . . . 3
  25.    3.   Format Rules . . . . . . . . . . . . . . . . . . . . . . . . 4
  26.    3a.   ASCII Format Rules  . . . . . . . . . . . . . . . . . . . . 4
  27.    3b.   PostScript Format Rules . . . . . . . . . . . . . . . . . . 5
  28.    4.   Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  29.    4a.   First Page Heading  . . . . . . . . . . . . . . . . . . . . 6
  30.    4b.   Running Header  . . . . . . . . . . . . . . . . . . . . . . 7
  31.    4c.   Running Footer  . . . . . . . . . . . . . . . . . . . . . . 7
  32.    5.   Status Section . . . . . . . . . . . . . . . . . . . . . . . 5
  33.    6.   Introduction Section . . . . . . . . . . . . . . . . . . . . 8
  34.    7.   References Section . . . . . . . . . . . . . . . . . . . . . 9
  35.    8.   Security Considerations Section  . . . . . . . . . . . . .  10
  36.    9.   Author's Address Section . . . . . . . . . . . . . . . . .  10
  37.    10.  Relation to other RFCs . . . . . . . . . . . . . . . . . .  10
  38.    11.  Protocol Standards Process . . . . . . . . . . . . . . . .  11
  39.    12.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  40.    13.  Distribution Lists . . . . . . . . . . . . . . . . . . . .  11
  41.    14.  RFC Index  . . . . . . . . . . . . . . . . . . . . . . . .  12
  42.    15.  Security Considerations  . . . . . . . . . . . . . . . . .  12
  43.    16.  References . . . . . . . . . . . . . . . . . . . . . . . .  12
  44.    17.  Author's Address . . . . . . . . . . . . . . . . . . . . .  12
  45.    18.  Appendix - RFC "nroff macros"  . . . . . . . . . . . . . .  13
  46.  
  47. 1.  Introduction
  48.  
  49.    This Request for Comments (RFC) provides information about the
  50.    preparation of RFCs, and certain policies relating to the publication
  51.    of RFCs.
  52.  
  53.    The RFC series of notes covers a broad range of interests.  The core
  54.    topics are the Internet and the TCP/IP protocol suite.  However, any
  55.  
  56.  
  57.  
  58. Postel                                                          [Page 1]
  59.  
  60. RFC 1543              Instructions to RFC Authors           October 1993
  61.  
  62.  
  63.    topic related to computer communication may be acceptable at the
  64.    discretion of the RFC Editor.
  65.  
  66.    Memos proposed to be RFCs may be submitted by anyone.  One large
  67.    source of memos that become RFCs is the Internet Engineering Task
  68.    Force (IETF).  The IETF working groups (WGs) evolve their working
  69.    memos (known as Internet Drafts or I-Ds) until they feel they are
  70.    ready for publication, then the memos are reviewed by the Internet
  71.    Engineering Steering Group (IESG), and if approved sent by the IESG
  72.    to the RFC Editor.
  73.  
  74.    RFCs are distributed online by being stored as public access files,
  75.    and a short message is sent to the distribution list indicating the
  76.    availability of the memo.
  77.  
  78.    The online files are copied by the interested people and printed or
  79.    displayed at their site on their equipment.  This means that the
  80.    format of the online files must meet the constraints of a wide
  81.    variety of printing and display equipment.  (RFCs may also be
  82.    returned via e-mail in response to an e-mail query, or RFCs may be
  83.    found using information and database searching tools such as Gopher,
  84.    Wais, WWW, or Mosaic.)
  85.  
  86.    RFCs have been traditionally published and continue to be published
  87.    in ASCII text.
  88.  
  89.    While the primary RFCs is always an ASCII text file, secondary or
  90.    alternative versions of RFC may be provided in PostScript.  This
  91.    decision is motivated by the desire to include diagrams, drawings,
  92.    and such in RFCs.  PostScript documents (on paper only, so far) are
  93.    visually more appealing and have better readability.
  94.  
  95.    PostScript was chosen for the fancy form of RFC publication over
  96.    other possible systems (e.g., impress, interpress, oda) because of
  97.    the perceived wide spread availability of PostScript capable
  98.    printers.
  99.  
  100.    However, many RFC users read the documents online and use various
  101.    text oriented tools (e.g., emacs, grep) to search them.  Often, brief
  102.    excerpts from RFCs are included in e-mail.  These practices are not
  103.    yet practical with PostScript files.
  104.  
  105.    PostScript producing systems are less standard than had been assumed
  106.    and that several of the document production systems that claim to
  107.    produce PostScript actually produce nonstandard results.
  108.  
  109.    In the future, it may be necessary to identify a set of document
  110.    production systems authorized for use in production of PostScript
  111.  
  112.  
  113.  
  114. Postel                                                          [Page 2]
  115.  
  116. RFC 1543              Instructions to RFC Authors           October 1993
  117.  
  118.  
  119.    RFCs, based on the reasonableness of the output files they generate.
  120.  
  121. 2.  Editorial Policy
  122.  
  123.    Documents proposed to be RFCs are reviewed by the RFC Editor and
  124.    possibly by other reviewers he selects.
  125.  
  126.    The result of the review may be to suggest to the author some
  127.    improvements to the document before publication.
  128.  
  129.    Occasionally, it may become apparent that the topic of a proposed RFC
  130.    is also the subject of an IETF Working Group, and that the author
  131.    could coordinate with the working group to the advantage of both.
  132.    The usual result of this is that a revised memo is produced as a
  133.    working group Internet Draft and eventually emerges from the IETF
  134.    process as a recommendation from the IESG to the RFC Editor.
  135.  
  136.    In some cases it may be determined that the submitted document is not
  137.    appropriate material to be published as an RFC.
  138.  
  139.    In some cases it may be necessary to include in the document a
  140.    statement based on the reviews about the ideas in the document.  This
  141.    may be done in the case that the document suggests relevant but
  142.    inappropriate or unsafe ideas, and other situations.
  143.  
  144.    The RFC Editor may make minor changes to the document, especially in
  145.    the areas of style and format, but on some occasions also to the
  146.    text.  Sometimes the RFC Editor will undertake to make more
  147.    significant changes, especially when the format rules (see below) are
  148.    not followed.  However, more often the memo will be returned to the
  149.    author for the additional work.
  150.  
  151.    Documents intended to become RFCs specifying standards track
  152.    protocols must be approved by the IESG before being sent to the RFC
  153.    Editor.  The established procedure is that when the IESG completes
  154.    work on a document that is to become a standards track RFC the
  155.    communication will be from the Secretary of the IESG to the RFC
  156.    Editor.  Generally, the documents in question are Internet Drafts.
  157.    The communication usually cites the exact Internet Draft in question
  158.    (by file name).  The RFC Editor must assume that only that file is to
  159.    be processed to become the RFC.  If the authors have small
  160.    corrections to the text, they should be sent to the RFC Editor
  161.    separately (or as a "diff"), do not send a new version of the
  162.    document.
  163.  
  164.    In some cases, authors prepare alternate secondary versions of RFCs
  165.    in fancy format using PostScript.  Since the ASCII text version of
  166.    the RFC is the primary version, the PostScript version must match the
  167.  
  168.  
  169.  
  170. Postel                                                          [Page 3]
  171.  
  172. RFC 1543              Instructions to RFC Authors           October 1993
  173.  
  174.  
  175.    text version.  The RFC Editor must decide if the PostScript version
  176.    is "the same as" the ASCII version before the PostScript version can
  177.    be published.
  178.  
  179.    The effect of this is that the RFC Editor first processes the ASCII
  180.    version of the memo through to publication as an RFC.  If the author
  181.    wishes to submit a PostScript version at that point that matches the
  182.    ASCII version (and the RFC Editor agrees that it does), then the
  183.    PostScript version will be installed in the RFC repositories and
  184.    announced to the community.
  185.  
  186.    Due to various time pressures on the RFC Editorial staff the time
  187.    elapsed between submission and publication can vary greatly.  It is
  188.    always acceptable to query (ping) the RFC Editor about the status of
  189.    an RFC during this time (but not more than once a week).  The two
  190.    weeks preceding an IETF meeting are generally very busy, so RFCs
  191.    submitted shortly before an IETF meeting are most likely to be
  192.    published after the meeting.
  193.  
  194. 3.  Format Rules
  195.  
  196.    To meet the distribution constraints, the following rules are
  197.    established for the two allowed formats for RFCs:  ASCII and
  198.    PostScript.
  199.  
  200.    The RFC Editor attempts to ensure a consistent RFC style.  To do this
  201.    the RFC Editor may choose to reformat the RFC submitted.  It is much
  202.    easier to do this if the submission matches the style of the most
  203.    recent RFCs.  Please do look at some recent RFCs and prepare yours in
  204.    the same style.
  205.  
  206.    You must submit an editable online document to the RFC Editor.  The
  207.    RFC Editor may require minor changes in format or style and will
  208.    insert the actual RFC number.
  209.  
  210.    Most of the RFCs are processed by the RFC Editor with the unix
  211.    "nroff" program using a very simple set of the formatting commands
  212.    (or "requests") from the "ms" macro package (see the appendix).  If a
  213.    memo submitted to be an RFC has been prepared by the author using
  214.    nroff, it is very helpful to let the RFC Editor know that when it is
  215.    submitted.
  216.  
  217.    3a.  ASCII Format Rules
  218.  
  219.       The character codes are ASCII.
  220.  
  221.       Each page must be limited to 58 lines followed by a form feed on a
  222.       line by itself.
  223.  
  224.  
  225.  
  226. Postel                                                          [Page 4]
  227.  
  228. RFC 1543              Instructions to RFC Authors           October 1993
  229.  
  230.  
  231.       Each line must be limited to 72 characters followed by carriage
  232.       return and line feed.
  233.  
  234.       No overstriking (or underlining) is allowed.
  235.  
  236.       These "height" and "width" constraints include any headers,
  237.       footers, page numbers, or left side indenting.
  238.  
  239.       Do not fill the text with extra spaces to provide a straight right
  240.       margin.
  241.  
  242.       Do not do hyphenation of words at the right margin.
  243.  
  244.       Do not use footnotes.  If such notes are necessary, put them at
  245.       the end of a section, or at the end of the document.
  246.  
  247.       Use single spaced text within a paragraph, and one blank line
  248.       between paragraphs.
  249.  
  250.       Note that the number of pages in a document and the page numbers
  251.       on which various sections fall will likely change with
  252.       reformatting.  Thus cross references in the text by section number
  253.       usually are easier to keep consistent than cross references by
  254.       page number.
  255.  
  256.       RFCs in ASCII Format may be submitted to the RFC Editor in e-mail
  257.       messages (or as online files) in either the finished publication
  258.       format or in NROFF.  If you plan to submit a document in NROFF
  259.       please consult the RFC Editor first.
  260.  
  261.    3b.  PostScript Format Rules
  262.  
  263.       Standard page size is 8 1/2 by 11 inches.
  264.  
  265.       Margin of 1 inch on all sides (top, bottom, left, and right).
  266.  
  267.       Main text should have a point size of no less than 10 points with
  268.       a line spacing of 12 points.
  269.  
  270.       Footnotes and graph notations no smaller than 8 points with a line
  271.       spacing of 9.6 points.
  272.  
  273.       Three fonts are acceptable: Helvetica, Times Roman, and Courier.
  274.       Plus their bold-face and italic versions.  These are the three
  275.       standard fonts on most PostScript printers.
  276.  
  277.       Prepare diagrams and images based on lowest common denominator
  278.       PostScript.  Consider common PostScript printer functionality and
  279.  
  280.  
  281.  
  282. Postel                                                          [Page 5]
  283.  
  284. RFC 1543              Instructions to RFC Authors           October 1993
  285.  
  286.  
  287.       memory requirements.
  288.  
  289.       The following PostScript commands should not be used:
  290.       initgraphics, erasepage, copypage, grestoreall, initmatrix,
  291.       initclip, banddevice, framedevice, nulldevice and renderbands.
  292.  
  293.       Note that the number of pages in a document and the page numbers
  294.       on which various sections fall will likely differ in the ASCII and
  295.       the PostScript versions.  Thus cross references in the text by
  296.       section number usually are easier to keep consistent than cross
  297.       references by page number.
  298.  
  299.       These PostScript rules are likely to changed and expanded as
  300.       experience is gained.
  301.  
  302.       RFCs in PostScript Format may be submitted to the RFC Editor in
  303.       e-mail messages (or as online files).  If you plan to submit a
  304.       document in PostScript please consult the RFC Editor first.
  305.  
  306.       Note that since the ASCII text version of the RFC is the primary
  307.       version, the PostScript version must match the text version.  The
  308.       RFC Editor must decide if the PostScript version is "the same as"
  309.       the ASCII version before the PostScript version can be published.
  310.  
  311. 4.  Headers and Footers
  312.  
  313.    There is the first page heading, the running headers, and the running
  314.    footers.
  315.  
  316.    4a.  First Page
  317.  
  318.       Please see the front page of this memo for an example of the front
  319.       page heading.  On the first page there is no running header.  The
  320.       top of the first page has the following items:
  321.  
  322.       Network Working Group
  323.  
  324.          The traditional heading for the group that founded the RFC
  325.          series.  This appears on the first line on the left hand side
  326.          of the heading.
  327.  
  328.       Request for Comments: nnnn
  329.  
  330.          Identifies this as a request for comments and specifies the
  331.          number.  Indicated on the second line on the left side.  The
  332.          actual number is filled in at the last moment before
  333.          publication by the RFC Editor.
  334.  
  335.  
  336.  
  337.  
  338. Postel                                                          [Page 6]
  339.  
  340. RFC 1543              Instructions to RFC Authors           October 1993
  341.  
  342.  
  343.       Author
  344.  
  345.          The author's name (first initial and last name only) indicated
  346.          on the first line on the right side of the heading.
  347.  
  348.       Organization
  349.  
  350.          The author's organization, indicated on the second line on the
  351.          right side.
  352.  
  353.       Date
  354.  
  355.          This is the Month and Year of the RFC Publication. Indicated on
  356.          the third line on the right side.
  357.  
  358.       Updates or Obsoletes
  359.  
  360.          If this RFC Updates or Obsoletes another RFC, this is indicated
  361.          as third line on the left side of the heading.
  362.  
  363.       Category
  364.  
  365.          The category of this RFC, one of: Standards Track,
  366.          Informational, or Experimental.  This is indicated on the third
  367.          (if there is no Updates or Obsoletes indication) or fourth line
  368.          of the left side.
  369.  
  370.       Title
  371.  
  372.          The title appears, centered, below the rest of the heading.
  373.  
  374.       If there are multiple authors and if the multiple authors are from
  375.       multiple organizations the right side heading may have additional
  376.       lines to accommodate them and to associate the authors with the
  377.       organizations properly.
  378.  
  379.    4b.  Running Headers
  380.  
  381.       The running header in one line (on page 2 and all subsequent
  382.       pages) has the RFC number on the left (RFC NNNN), the (possibly a
  383.       shortened form) title centered, and the date (Month Year) on the
  384.       right.
  385.  
  386.    4c.  Running Footers
  387.  
  388.       The running footer in one line (on all pages) has the author's
  389.       last name on the left and the page number on the right ([Page N]).
  390.  
  391.  
  392.  
  393.  
  394. Postel                                                          [Page 7]
  395.  
  396. RFC 1543              Instructions to RFC Authors           October 1993
  397.  
  398.  
  399. 5.  Status Section
  400.  
  401.    Each RFC must include on its first page the "Status of this Memo"
  402.    section which contains a paragraph describing the type of the RFC.
  403.  
  404.    The content of this section will be one of the three following
  405.    statements.
  406.  
  407.    Standards Track
  408.  
  409.       "This document specifies an Internet standards track protocol for
  410.       the Internet community, and requests discussion and suggestions
  411.       for improvements.  Please refer to the current edition of the
  412.       "Internet Official Protocol Standards" (STD 1) for the
  413.       standardization state and status of this protocol.  Distribution
  414.       of this memo is unlimited."
  415.  
  416.    Experimental
  417.  
  418.       "This memo defines an Experimental Protocol for the Internet
  419.       community.  This memo does not specify an Internet standard of any
  420.       kind.  Discussion and suggestions for improvement are requested.
  421.       Distribution of this memo is unlimited."
  422.  
  423.    Informational
  424.  
  425.       "This memo provides information for the Internet community.  This
  426.       memo does not specify an Internet standard of any kind.
  427.       Distribution of this memo is unlimited."
  428.  
  429. 6.  Introduction Section
  430.  
  431.    Each RFC should have an Introduction section that (among other
  432.    things) explains the motivation for the RFC and (if appropriate)
  433.    describes the applicability of the protocol described.
  434.  
  435.       Some example paragraphs are:
  436.  
  437.          Protocol
  438.  
  439.             This protocol is intended to provide the bla-bla service,
  440.             and be used between clients and servers on host computers.
  441.             Typically the clients are on workstation hosts and the
  442.             servers on mainframe hosts.
  443.  
  444.             or
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Postel                                                          [Page 8]
  451.  
  452. RFC 1543              Instructions to RFC Authors           October 1993
  453.  
  454.  
  455.             This protocol is intended to provide the bla-bla service,
  456.             and be used between special purpose units such as terminal
  457.             servers or routers and a monitoring host.
  458.  
  459.          Discussion
  460.  
  461.             The purpose of this RFC is to focus discussion on particular
  462.             problems in the Internet and possible methods of solution.
  463.             No proposed solutions in this document are intended as
  464.             standards for the Internet.  Rather, it is hoped that a
  465.             general consensus will emerge as to the appropriate solution
  466.             to such problems, leading eventually to the adoption of
  467.             standards.
  468.  
  469.          Interest
  470.  
  471.             This RFC is being distributed to members of the Internet
  472.             community in order to solicit their reactions to the
  473.             proposals contained in it.  While the issues discussed may
  474.             not be directly relevant to the research problems of the
  475.             Internet, they may be interesting to a number of researchers
  476.             and implementers.
  477.  
  478.          Status Report
  479.  
  480.             In response to the need for maintenance of current
  481.             information about the status and progress of various
  482.             projects in the Internet community, this RFC is issued for
  483.             the benefit of community members.  The information contained
  484.             in this document is accurate as of the date of publication,
  485.             but is subject to change.  Subsequent RFCs will reflect such
  486.             changes.
  487.  
  488.       These paragraphs need not be followed word for word, but the
  489.       general intent of the RFC must be made clear.
  490.  
  491. 7.  References Section
  492.  
  493.    Nearly all RFCs contain citations to other documents, and these are
  494.    listed in a References section near the end of the RFC.  There are
  495.    many styles for references, and the RFCs have one of their own.
  496.    Please follow the reference style used in recent RFCs.  See the
  497.    reference section of this RFC for an example.  Please note that for
  498.    protocols that have been assigned STD numbers, the STD number must be
  499.    included in the reference.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Postel                                                          [Page 9]
  507.  
  508. RFC 1543              Instructions to RFC Authors           October 1993
  509.  
  510.  
  511. 8.  Security Considerations Section
  512.  
  513.    All RFCs must contain a section near the end of the document that
  514.    discusses the security considerations of the protocol or procedures
  515.    that are the main topic of the RFC.
  516.  
  517. 9.  Author's Address Section
  518.  
  519.    Each RFC must have at the very end a section giving the author's
  520.    address, including the name and postal address, the telephone number,
  521.    (optional: a FAX number) and the Internet e-mail address.
  522.  
  523. 10.  Relation to other RFCs
  524.  
  525.    Sometimes an RFC adds information on a topic discussed in a previous
  526.    RFC or completely replaces an earlier RFC.  There are two terms used
  527.    for these cases respectively, UPDATES and OBSOLETES.  A document that
  528.    obsoletes an earlier document can stand on its own.  A document that
  529.    merely updates an earlier document cannot stand on its own; it is
  530.    something that must be added to or inserted into the previously
  531.    existing document, and has limited usefulness independently.  The
  532.    terms SUPERSEDES and REPLACES are no longer used.
  533.  
  534.    UPDATES
  535.  
  536.       To be used as a reference from a new item that cannot be used
  537.       alone (i.e., one that supplements a previous document), to refer
  538.       to the previous document.  The newer publication is a part that
  539.       will supplement or be added on to the existing document; e.g., an
  540.       addendum, or separate, extra information that is to be added to
  541.       the original document.
  542.  
  543.    OBSOLETES
  544.  
  545.       To be used to refer to an earlier document that is replaced by
  546.       this document.  This document contains either revised information,
  547.       or else all of the same information plus some new information,
  548.       however extensive or brief that new information is; i.e., this
  549.       document can be used alone, without reference to the older
  550.       document.
  551.  
  552.       For example:
  553.  
  554.          On the Assigned Numbers RFCs the term OBSOLETES should be used
  555.          since the new document actually incorporate new information
  556.          (however brief) into the text of existing information and is
  557.          more up-to-date than the older document, and hence, replaces it
  558.          and makes it OBSOLETE.
  559.  
  560.  
  561.  
  562. Postel                                                         [Page 10]
  563.  
  564. RFC 1543              Instructions to RFC Authors           October 1993
  565.  
  566.  
  567.    In lists of RFCs or the RFC-Index (but not on the RFCs themselves)
  568.    the following may be used with early documents to point to later
  569.    documents.
  570.  
  571.    OBSOLETED-BY
  572.  
  573.       To be used to refer to the newer document(s) that replaces the
  574.       older document.
  575.  
  576.    UPDATED-BY
  577.  
  578.       To be used to refer to the newer section(s) which are to be added
  579.       to the existing, still used, document.
  580.  
  581. 11.  Protocol Standards Process
  582.  
  583.    See the current "Internet Official Protocol Standards" (STD 1) memo
  584.    for the definitive statement on protocol standards and their
  585.    publication [1].
  586.  
  587.    The established procedure is that when the IESG completes work on a
  588.    document that is to become a standards track RFC the communication
  589.    will be from the Secretary of the IESG to the RFC Editor.  Generally,
  590.    the documents in question are Internet Drafts.  The communication
  591.    usually cites the exact Internet Draft (by file name) in question.
  592.    The RFC Editor must assume that only that file is to be processed to
  593.    become the RFC.  If the authors have small corrections to the text,
  594.    they should be sent to the RFC Editor separately (or as a "diff"), do
  595.    not send a new version of the document.
  596.  
  597. 12.  Contact
  598.  
  599.    To contact the RFC Editor send an email message to
  600.  
  601.          "RFC-Editor@ISI.EDU".
  602.  
  603. 13.  Distribution Lists
  604.  
  605.    The RFC announcements are distributed via two mailing lists: the
  606.    "IETF-Announce" list, and the "RFC-DIST" list.  You don't want to be
  607.    on both lists.
  608.  
  609.    To join (or quit) the IETF-Announce list send a message to IETF-
  610.    Request@cnri.reston.va.us.
  611.  
  612.    To join (or quit) the RFC-DIST list send a message to RFC-
  613.    Request@NIC.DDN.MIL.
  614.  
  615.  
  616.  
  617.  
  618. Postel                                                         [Page 11]
  619.  
  620. RFC 1543              Instructions to RFC Authors           October 1993
  621.  
  622.  
  623. 14.  RFC Index
  624.  
  625.    Several organizations maintain RFC Index files, generally using the
  626.    file name "rfc-index.txt".  The contents of such a file copied from
  627.    one site may not be identical to that copied from another site.
  628.  
  629. 15.  Security Considerations
  630.  
  631.    This RFC raises no security issues (however, see Section 6).
  632.  
  633. 16.  References
  634.  
  635.  
  636.    [1]  Postel, J., "Internet Official Protocol Standards", STD 1, RFC
  637.         1540, Internet Architecture Board, October 1993.
  638.  
  639. 17.  Author's Address
  640.  
  641.    Jon Postel
  642.    USC/Information Sciences Institute
  643.    4676 Admiralty Way
  644.    Marina del Rey, CA  90292
  645.  
  646.    Phone: 310-822-1511
  647.    Fax:   310-823-6714
  648.    EMail: Postel@ISI.EDU
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Postel                                                         [Page 12]
  675.  
  676. RFC 1543              Instructions to RFC Authors           October 1993
  677.  
  678.  
  679. 18.  Appendix - RFC "nroff macros"
  680.  
  681.    Generally, we use the very simplest nroff features.  We use the "ms"
  682.    macros.  So, "nroff -ms input-file > output-file".  However, we could
  683.    not get nroff to do the right thing about putting a form feed after
  684.    the last visible line on a page and no extra line feeds before the
  685.    first visible line of the next page.  We want:
  686.  
  687.         last visible line on page i
  688.         ^L
  689.         first visible line on page i+1
  690.  
  691.    So, we invented some hacks to fix this including a "sed" script
  692.    called "fix.sh" and a "c" program we called "pg" (pg is called from
  693.    fix).  So the command to process the file becomes:
  694.  
  695.         nroff -ms input-file | fix.sh > output-file
  696.  
  697.    Now as to the nroff features we actually use, I'll append a sample
  698.    memo, prepared in RFC style.
  699.  
  700.    The sed script fix.sh is:
  701.  
  702.         sed -e 's/FORMFEED\[Page/        \[Page/' $* | pg -n5
  703.  
  704. The pg program is:
  705.  
  706.                      ~~~Beginning of pg program~~~
  707.  
  708. /* $Header$
  709.  *
  710.  *  Remove N lines following any line that contains a form feed (^L).
  711.  *  (Why can't this be done with awk or sed?)
  712.  *
  713.  *  OPTION:
  714.  *      -n#     Number of lines to delete following each ^L (0 default).
  715.  * $Log$
  716.  */
  717. #include <stdio.h>
  718. #define FORM_FEED       '\f'
  719. #define OPTION          "n:N:"          /* for getopt() */
  720.  
  721. extern char *optarg;
  722. extern int optind;
  723.  
  724. main(argc, argv)
  725. int     argc;
  726. char    *argv[];
  727.  
  728.  
  729.  
  730. Postel                                                         [Page 13]
  731.  
  732. RFC 1543              Instructions to RFC Authors           October 1993
  733.  
  734.  
  735. {
  736.   int   c,                              /* next input char */
  737.         nlines = 0;                     /* lines to delete after ^L */
  738.   void  print_and_delete();             /* print line starting with ^L,
  739.                                            then delete N lines */
  740.  
  741. /* Process option (-nlines) */
  742.  
  743.   while ((c = getopt(argc, argv, OPTION)) != EOF)
  744.     switch(c)
  745.     {
  746.       case 'n' :
  747.       case 'N' :  nlines = atoi(optarg);
  748.                   break;
  749.     }
  750. /* READ AND PROCESS CHARS */
  751.  
  752.   while ((c = getchar()) != EOF)
  753.     if (c == FORM_FEED)
  754.       print_and_delete(nlines);  /* remove N lines after this one */
  755.     else
  756.       putchar(c);                /* we write the form feed */
  757.   exit(0);
  758. }
  759.  
  760. /* Print rest of line, then delete next N lines. */
  761.  
  762. void print_and_delete(n)
  763. int  n;                                 /* nbr of lines to delete */
  764. {
  765.   int   c,                              /* next input char */
  766.         cntr = 0;                       /* count of deleted lines */
  767.  
  768.   while ((c = getchar()) != '\n')       /* finish current line */
  769.     putchar(c);
  770.   putchar('\n');                        /* write the last CR */
  771.   putchar(FORM_FEED);
  772.  
  773.   for ( ; cntr < n; cntr++)
  774.     while ((c = getchar()) != '\n')
  775.       if (c == EOF)
  776.         exit(0);                        /* exit on EOF */
  777.   putchar(c);                           /* write that last CR */
  778. }
  779.                         ~~~End of pg program~~~
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Postel                                                         [Page 14]
  787.  
  788. RFC 1543              Instructions to RFC Authors           October 1993
  789.  
  790.  
  791. .pl 10.0i
  792. .po 0
  793. .ll 7.2i
  794. .lt 7.2i
  795. .nr LL 7.2i
  796. .nr LT 7.2i
  797. .ds LF Waitzman
  798. .ds RF FORMFEED[Page %]
  799. .ds CF
  800. .ds LH RFC 1149
  801. .ds RH 1 April 1990
  802. .ds CH IP Datagrams on Avian Carriers
  803. .hy 0
  804. .ad l
  805. .in 0
  806. Network Working Group                                        D. Waitzman
  807. Request for Comments: 1149                                       BBN STC
  808.                                                             1 April 1990
  809.  
  810.  
  811. .ce
  812. A Standard for the Transmission of IP Datagrams on Avian Carriers
  813.  
  814. .ti 0
  815. Status of this Memo
  816.  
  817. .fi
  818. .in 3
  819. This memo describes an experimental method for the encapsulation of IP
  820. datagrams in avian carriers.  This specification is primarily useful
  821. in Metropolitan Area Networks.  This is an experimental, not recommended
  822. standard.  Distribution of this memo is unlimited.
  823.  
  824. .ti 0
  825. Overview and Rational
  826.  
  827. Avian carriers can provide high delay, low throughput, and low
  828. altitude service.  The connection topology is limited to a single
  829. point-to-point path for each carrier, used with standard carriers, but
  830. many carriers can be used without significant interference with each
  831. other, outside of early spring.  This is because of the 3D ether space
  832. available to the carriers, in contrast to the 1D ether used by
  833. IEEE802.3.  The carriers have an intrinsic collision avoidance system,
  834. which increases availability.  Unlike some network technologies, such
  835. as packet radio, communication is not limited to line-of-sight
  836. distance.  Connection oriented service is available in some cities,
  837. usually based upon a central hub topology.
  838.  
  839.  
  840.  
  841.  
  842. Postel                                                         [Page 15]
  843.  
  844. RFC 1543              Instructions to RFC Authors           October 1993
  845.  
  846.  
  847. .ti 0
  848. Frame Format
  849.  
  850. The IP datagram is printed, on a small scroll of paper, in
  851. hexadecimal, with each octet separated by whitestuff and blackstuff.
  852. The scroll of paper is wrapped around one leg of the avian carrier.
  853. A band of duct tape is used to secure the datagram's edges.  The
  854. bandwidth is limited to the leg length.  The MTU is variable, and
  855. paradoxically, generally increases with increased carrier age.  A
  856. typical MTU is 256 milligrams.  Some datagram padding may be needed.
  857.  
  858. Upon receipt, the duct tape is removed and the paper copy of the
  859. datagram is optically scanned into a electronically transmittable
  860. form.
  861.  
  862. .ti 0
  863. Discussion
  864.  
  865. Multiple types of service can be provided with a prioritized pecking
  866. order.  An additional property is built-in worm detection and
  867. eradication.  Because IP only guarantees best effort delivery, loss of
  868. a carrier can be tolerated.  With time, the carriers are
  869. self-regenerating.  While broadcasting is not specified, storms can
  870. cause data loss.  There is persistent delivery retry, until the
  871. carrier drops.  Audit trails are automatically generated, and can
  872. often be found on logs and cable trays.
  873.  
  874. .ti 0
  875. Security Considerations
  876.  
  877. .in 3
  878. Security is not generally a problem in normal operation, but special
  879. measures must be taken (such as data encryption) when avian carriers
  880. are used in a tactical environment.
  881.  
  882. .ti 0
  883. Author's Address
  884.  
  885. .nf
  886. David Waitzman
  887. BBN Systems and Technologies Corporation
  888. BBN Labs Division
  889. 10 Moulton Street
  890. Cambridge, MA 02238
  891.  
  892. Phone: (617) 873-4323
  893.  
  894. EMail: dwaitzman@BBN.COM
  895.  
  896.  
  897.  
  898. Postel                                                         [Page 16]
  899.  
  900.